Titre un peu provocateur mais très sérieux en tentant d’être visionnaire sur l’avenir du domaine. J’ai commencé à rédiger cet article juste avant de voir un article d’Oleg Shilovitsky : Aras and Search for new PLM Business Model. Dans cet article, Oleg pose la réflexion de nouveaux modèles économiques pour le PLM. Il rappelle l’infographie qui a fait récemment le tour des réseaux sociaux (Airbnb numéro de un l’hôtellerie sans aucune chambre, Uber numéro un des taxis sans posséder un seul taxi,…).
Ensuite dans son article il poursuit sur la problématique de proposition d’un nouveau modèle économique pour les clients du PLM. Cependant, après avoir pris les exemples d’Uber et d’Airbnb, je m’attendais plus à étudier l’élément important de ces startups qui ne tient pas forcément à leur modèle économique, mais en partie à la fourniture d’une technologie qui permet de mettre en relation des biens/ressources (taxis, appartements) et des consommateurs.
Airbnb et Uber du PLM, ce serait quoi?
Donc si je poursuis la comparaison, sans prendre la voie du modèle économique. Le capital de la solution PLM c’est sa donnée principale à travers ses articles, ses nomenclatures, ses documents. C’est l’élément compliqué à fabriquer ou à importer, comme les hotels et les taxis. La transposition de ces startups au PLM serait alors de fournir la technologie qui permette aux utilisateurs de manipuler cette donnée core sans que la solution la possède ou l’importe.
Comme pour Airbnb, il y a un pré-requis obligatoire, le capital. Il faut alors :
- que les données existent quelques part (les appartements existaient déjà)
- qu’elles soient représentées dans un format connu voir standard pour que la solution puisse interagir avec. (tous les appartements ont un propriétaire qui gère l’accès des locataires,…)
- que soit pris en compte le fait que ces données ne soient pas forcément utilisées que par la solution PLM.(chaque appartement est aussi potentiellement utilisé par le propriétaire, la données pourrait être utilisée par une solution ERP ou autre)
step.io ?
Vous rappelez-vous de cet article que j’avais rédigé en mai dernier à propos d’une API pour des données de patients d’hopitaux qui m’inspirait la possibilité d’une API pour gérer des données PLM? C’est, je pense, dans cette voie que se situe la vraie transposition du modèle Airbnb/Uber au PLM. Comment cela est-il réalisable?
- Il faut d’abord définir un modèle de données ou pour faire les choses correctement, reprendre les standards les plus prometteurs et reprendre leur modèle de données.
- Mettre en place une API d’interfaçage avec les principales fonctions de mises à jour des informations selon le standard choisi.
- Fournir une interface simple pour favoriser l’adoption des « early adoopters » en leur permettant d’importer rapidement leurs données sur cette plateforme.
On jette le reste des PLM?
Justement non, le but est de permettre aux éditeurs du PLM de se concentrer sur leur vrai métier qui est de proposer des fonctionnalités de gestion de configuration, de gestion de projet, de collaboration,…
Les avantages?
L’avantage principal c’est de pouvoir favoriser un éco-systèmes de solutions PLM qui pourront être beaucoup plus découpées par fonction. Vous pourriez choisir vos modules fonctionnels, ou basculer d’un éditeur à un autre tout en conservant votre donnée intacte dans un système de master de données indépendant. La migration de données est une des plus grosses phase d’un projet PLM et donc un des plus important lock-in pour les éditeurs. Séparer la donnée (ce que certains font déjà avec une couche de données en interne de leur société et indépendant de la solution PLM) permet d’obtenir une réelle liberté de sélection de l’éditeur (ou des éditeurs) et de faciliter la création d’autres fonctionnalités PLM.
Des personnes inspirées??? en attendant je prototype le week-end !
playing with deployd to build a PLM API !!! #prototype #api http://t.co/BAbnFyHkUx #plm
— yoann maingon (@yoannmaingon) August 30, 2015
Bonjour,
Intéressant. Petite interrogation : est-il possible de réaliser une api sans standardisation des échanges de données ? Vous basez-vous sur un standard?
Je pense que pour lancer le concept, il faut proposer une API qui va permettre de jouer avec des articles des nomenclatures et des documents attachés pourrait suffire. Cependant cela n’empêche pas de partir sur la base de STEP, qui regroupe ces objets au milieu d’un modèle de données beaucoup plus riche que l’on peut ignorer au lancement.
Et beaucoup de solutions différencient leur modèle de données et le format d’échange (la plupart des solutions exportent en STEP sans pour autant avoir un modèle STEP en interne de leur solution). Je pense qu’il faut repartir de STEP et ne pas différencier le format d’échange.